Illumination control network

ABSTRACT

The present invention addresses the problem of providing illumination in a manner that is energy efficient and intelligent. In particular, the present invention uses distributed processing across a network of illuminators to control the illumination for a given environment. The network controls the illumination level and pattern in response to light, sound, and motion. The network may also be trained according to uploaded software behavior modules, and subsets of the network may be organized into groups for illumination control and maintenance reporting.

RELATED APPLICATIONS

This applicationThe present application is a divisional reissue of U.S.patent application No. 14/051,709, entitled ILLUMINATION CONTROLNETWORK, issued as U.S. Pat. No. RE46,430 on Jun. 6, 2017, which is areissue of U.S. Pat. No. 8,035,320, entitled ILLUMINATION CONTROLNETWORK, which issued on Oct. 11, 2011, which claims the benefit of U.S.Provisional Application No. 60/913,796, filed on Apr. 24, 2007 and ofU.S. Provisional Application No. 60/912,997, filed on Apr. 20, 2007. Theentire teachings of the above applications are incorporated herein byreference.

More than one divisional reissue application has been filed for thereissue of Pat. No. 8,035,320. In addition to the present application,the divisional reissue applications Ser. Nos. are 15/494,694;15/494,799, issued as U.S. Pat. No. RE48,090 on Jul. 7, 2020; andapplication Ser. No. 15/892,797.

BACKGROUND OF THE INVENTION

From a user perspective, the goals of lighting control are three-fold:(1) flexibility: control lighting in accordance with the user's desires;(2) ease of use: control lighting in a way that is straightforward andintuitive for the user; and (3) control lighting in a way that optimizesresource (energy) consumption. Current technologies enable control thatsatisfies those goals to a modest degree.

Control of lighting (illumination) and other building systems today islargely dominated by three approaches: (1) hardwired local control, suchas conventional toggle light switches and dimmers; (2) hardwired localcontrol augmented by hardwired sensors, such as motion sensing lightswitches; and (3) hardwired centralized control, such as systemsincorporating a control computer that explicitly commands individuallights or lighting circuits to turn on, turn off, and dim. Such localcontrols directly accomplish the intent of the human operator whoactivates them. Such centralized controls allow for programmed behaviorsbut exercise very explicit control over operation of the individuallights. Such centralized controls also typically require detailed andexplicit “commissioning” activities to program the desired operationsfor individual lights. Often, centralized control systems utilizeprotocols such as DMX512 and DALI (digital addressable lightinginterface) to issue commands to individual lights.

Some technologies separate control activation (e.g., the light switch)from the controlled light or other device. An early example of thiscontrol is the X10 system, a one-way control system relying ontransmission of low-frequency signals over the AC power line. A morerecent example of similar technology is the Insteon system, which usesan AC signaling system like X10, but uses acknowledgments to make theprotocol more reliable. Wireless systems are also used, including bothproprietary wireless and industry-standard initiatives such as the HomeAutomation Profile of the ZigBee wireless mesh network standard, orlower-level protocols relying on the IEEE 802.15.4 standard (which alsounderlies ZigBee). These systems, particularly the wireless ones, can beeasier to install than hardwired systems. Like the hardwired local andcentralized controls that they replace, these systems typically requireexplicit “commissioning” activities to achieve the desired results.

Illumination produced by light-emitting diodes (LEDs) is particularlydesirable both from an energy consumption standpoint (since currentlaboratory LEDs are the most efficient general-purpose light emitters inexistence today, and they are following a clear path to furtherimprovement) and from a control flexibility standpoint. LEDs also havesignificant other advantages in packaging flexibility, lifetime, size,and durability. Most current LED-based light sources for generalillumination are relatively primitive, in that they incorporate nobuilt-in control mechanisms, and simply supply the constant DC currentneeded to operate the LEDs, sometimes using pulse-width modulation (PWM)to adjust brightness. Some LED sources are more sophisticated, allowingdynamic adjustment of color. Such sources typically are controlled in acentralized fashion, in part because the complexity of control requiredfor such adjustments can be difficult to express with a simple locallyactuated control.

Although illumination by LEDs is advantageous from a technology andlifetime standpoint, the cost of LED illumination devices issignificantly greater than conventional light sources such asincandescent or fluorescent bulbs. The very long inherent lifetime ofLED sources is also at odds with the traditional distinction betweenpermanently installed lighting fixtures and replaceable light bulbs. LEDlighting is likely to be packaged as complete units, combining thefixture and light source without any intent that the source be easilyreplaceable. Although LED light sources can fail, such a failure can betreated as a repair, rather than as an expected and regularintervention.

Inasmuch as existing technologies for control of lighting and/or otherbuilding systems rely on localized controls or centralized controls,those technologies do not provide the degree of flexibility and ease ofuse that is desirable for taking full advantage of the capabilities andattributes of LED lighting.

SUMMARY OF THE INVENTION

Inasmuch as existing technologies for control of lighting and/or otherbuilding systems rely on localized controls or centralized controls,those technologies do not provide the degree of flexibility and ease ofuse that is desirable for taking full advantage of the capabilities andattributes of LED light sources. Their output can be readily adjustedwithout penalty in color, lifetime, or other areas across an enormousrange of intensity. Their long lifetime makes it cost-effective toamortize the cost of control circuitry components across that lifetime.In fact, sophisticated controls are essential for achieving that longlifetime, because the brightness and color spectrum of LED emitters canchange significantly over that lifetime.

The present invention takes advantage of the technical and economicproperties of LED lighting sources by integrating a controlmicroprocessor with each light source to form an illuminator. Enablingthe control microprocessors in different illuminators to communicatewith each other makes it possible to coordinate the behavior of acollection of illuminators. Such coordination is particularly valuablefor illuminators within an enclosed space (e.g., a room), where it isdesirable for plural illuminators to operate together to provideillumination that is perceived by users as being uniform and effective.

In certain embodiments, the illuminators comprise a light source, one ormore sensors, at least one communications interface, and at least oneprocessor. The light source may be a plurality of LEDs, which maycomprise LEDs of at least two different colors; manipulating theemission of the different color LEDs changes the perceived color of theemitted illumination. In other embodiments, the light sources may befluorescent, incandescent, or metal-halide light bulbs.

One or more sensors may be integrated into the illuminator to monitorsuch parameters as ambient light levels, ambient motion, ambient sound,and the electrical parameters of the illuminator itself. For example,the sensor may respond to the forward current of the LED, providing ameasure of the power consumed by the illuminator or the expectedlifetime of the LED. The sensor may also detect external stimuli such assunlight or motion; detection of such stimuli may lead the illuminator'sprocessor to change the illumination intensity or color. The sensor mayeven detect motion or voice commands.

To enable coordinated operation, the illuminators each havecommunications interfaces for communicating with other illuminators andwith external controllers. The communications interfaces may useinfrared radiation, ultrasound waves, radio-frequency waves, or signalssent over wires or fiber-optic links to communicate. In disclosedembodiments, illuminators use infrared radiation to communicate withtheir neighbors and wireless radio-frequency gateways to communicatewith illuminators that cannot be reached with infrared links.

In the disclosed embodiments, the plurality of illuminators form adistributed network that makes coordinated lighting decisions based onthe output from the sensors and the communications interfaces. Theprocessors in the illuminators respond to these data, changing theintensity, pattern, and color of the emitted light. In oneimplementation, the processors respond according the a weighted pollingalgorithm.

The processors also communicate with fixed and handheld directors, whichcan be used to control and configure the illuminators directly. Thedirectors may also be used to upload software modules, or behaviors,that influence the lighting decisions of the distributed network.Behaviors (for example, the ability to learn and replay lightingpatterns) can be delivered to the control microprocessors as independentsoftware modules. Such modules could, for example, be provided asseparately purchased software upgrades for existing hardware, enablinglighting sources to provide more sophisticated functions with no change,modification, or alteration to the sources themselves.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the system architecture of a basic illuminations controlnetwork (ICN) application.

FIG. 2 shows additional system components that can be integrated withthe basic application shown in FIG. 1.

FIG. 3 shows applicability of ICN control techniques to other types ofdevice.

FIG. 4 shows the elements of an ICN controller.

FIG. 5 shows an ICN controller integrated with an LED lighting source.

FIG. 6A shows components internal to a battery-powered fixed-functiondirector

FIG. 6B shows components internal to a photovoltaic-poweredfixed-function director.

FIG. 7 shows components internal to a full-function director.

FIG. 8 shows the structure of software components in a typicalcontroller implementation.

FIG. 9 shows the internal components of a typical controlmicroprocessor.

FIG. 10 shows operation of the power control interrupt handler.

FIG. 11 shows data structures used by the power control interrupthandler.

FIG. 12 shows data structures used by the communication transmitinterrupt handler.

FIG. 13 shows data structures used by the communication network layer.

FIG. 14 shows a simple group broadcast operation.

FIG. 15 shows data structures used for single-unit occupancy sensing

FIG. 16 shows operation of single-unit occupancy sensing

The foregoing will be apparent from the following more particulardescription of example embodiments of the invention, as illustrated inthe accompanying drawings in which like reference characters refer tothe same parts throughout the different views. The drawings are notnecessarily to scale, emphasis instead being placed upon illustratingembodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION 1 Introduction

A description of example embodiments of the invention follows.

The teachings of all patents, published applications and referencescited herein are incorporated by reference in their entirety.

Traditional lighting sources (such as incandescent bulbs, fluorescentlamps, metal halide lamps, etc.) can be turned on and off, but providevery little additional flexibility of control. For example, incandescentlamps can be dimmed, but only at the cost of dramatic diminution inenergy efficiency and an undesirable color shift to the red end of thespectrum. Similarly, fluorescent lamps can be dimmed, but only within alimited range and through use of sophisticated high-voltage powercontrol circuitry that is incompatible with the dimmers used forincandescent lamps. Metal halide lamps are even less practical to dim,and although highly efficient, have relatively very long startup andcool-down times. The above-cited drawbacks represent only a few of thedisadvantages of conventional light sources, the overall effect of whichis to limit the utility of sophisticated control capabilities.

LED light sources, on the other hand, have the capability to supportmuch more sophisticated controls. Their output can be readily adjustedwithout penalty in color, lifetime, or other areas (and even with amodest improvement in energy efficiency depending on the dimmingtechnology) across an enormous range of intensity (over 5000 to 1).Their long lifetime (100,000 hours or more) makes it cost-effective toamortize the cost of control circuitry components across that lifetime.In fact, sophisticated (internal) controls are essential for achievingthat long lifetime, because the brightness and color spectrum of LEDemitters can change significantly over that lifetime. Such changes arealso caused by changes in operating temperature, and are the naturalresult of manufacturing variations: nominally identical LED componentscan exhibit significantly different intensities and color spectra.

Compared to most conventional light sources, LED light sources arerelatively costly to manufacture. Although this higher cost is, in thelong term, compensated by the greater energy efficiency and longerlifetime of LEDs, in practice the high first cost of LED lighting is asignificant economic barrier to its use.

The present invention takes advantage of the technical and economicproperties of LED lighting sources by integrating a controlmicroprocessor with each light source or other controlled appliance andenabling the control microprocessors to communicate with each other toprovide coordinated behaviors across a collection of light sources. Suchcoordination is particularly valuable for light sources within a singlephysical space (e.g., a room or other enclosed area), where it isdesirable for multiple light sources to operate together to provideillumination that is perceived by users as being uniform and effective.With conventional control mechanisms and light sources, control might beapplied (e.g., by hard-wiring or configuring all the light sources in aroom to turn on and off together) to yield uniformity of lightingsources—but the real value comes from the perceived utility andeffectiveness of the light for users, not for the sources.

Integrating a control microprocessor with each light source or othercontrolled appliance allows the controlled units to be programmed withdifferent behaviors. Behaviors (for example, the ability to learn andreplay lighting patterns) can be delivered to the controlmicroprocessors as independent software modules. Such modules could, forexample, be provided as separately purchased software upgrades forexisting hardware, enabling lighting sources to provide moresophisticated functions with no change, modification, or alteration tothe sources themselves.

The economic characteristics of LED lighting (long lifetime, highinitial cost) encourage the use of different economic models than forconventional light sources. For example, it may be more cost-effectivefor a customer to lease LED lighting fixtures (thus ensuring continuingaccess to maintenance) than to purchase them. The present inventionprovides for software to control and enforce such leasing, byestablishing a continuing electronic relationship between the supplierand customer.

The present invention describes an architecture for controlling theoperation of light sources and/or other appliances. The architectureprovides for self-organizing autonomous control: a system in whichelements such as LED light sources communicate and interact with eachother to provide behaviors appropriate to the environment in which theyoperate, based on minimal human interaction and configuration. Thesystem learns the desired behavior by responding to human requests andmodifying its behavior in response to those requests. One aspect of theidea is that behaviors can be defined by independently loadable softwaremodules that are installed on a within the system elements so that anindividual element can exhibit a wide variety of behaviors.

One goal of the Illumination Control Network (ICN) architecture is tocombine the many advantages of light-emitting diode (LED) light sourceswith the additional capabilities provided by integrating local digitalmicroprocessor control into each light source. LED light sources offermajor energy efficiency improvements relative to conventional sources,and the combination with autonomous distributed control can furtherreduce energy costs by ensuring that light is produced only whenactually needed. In addition, once such a control mechanism is present,the same control, sensor, and communication facilities can enable a widevariety of other functions for behavior customization, system control,and integration with building management and security systems. Inaddition, since the control platform is built around a general-purposemicroprocessor running an arbitrary set of software modules, thesystem's control, sensor, and communication functions of the system canalso be used to control arbitrary other types of devices, and to providetransport for other types of data.

2 Architectural Components

FIG. 1 shows an example ICN implementation comprising pluralilluminators 111, a fixed-function director 122, a flexible director123, and a configurator 141. All these elements are installed and/oroperated within the confines of a room 201. These elements communicatewith each other by sending messages with infrared communication signals524.

There are many possible designs for illuminator 111, depending on theamount of light to be produced, power sources (e.g., AC line, DC,battery), thermal considerations, and control requirements. Althoughthis description focuses on LED-based illuminators, it is of coursepossible to use other light sources such as incandescent, fluorescent,halogen, and/or high-intensity discharge, although some controlbehaviors may not be practically realizable with such non-LED lightsources.

FIG. 2 shows a more complex example ICN implementation consisting ofplural rooms 201, optically isolated from each other by opaque roomwalls, each containing plural illuminators 111. In FIG. 2, combinedconfigurator/director 151 takes the place of configurator 141 andflexible director 123. Fixed-function directors 122 are present in eachof rooms 201. Gateway 161 enables communication between different rooms201, which would otherwise block infrared control messages 524 withtheir opaque walls. Gateway 161 can also incorporate other communicationinterfaces, such as wireless signal 551 or Ethernet interface 561.

As is evident from the description herein, FIGS. 1 and 2 are onlyexamples of potentially arbitrary combinations of elements in an ICNimplementation. Because light sources provide an easily-understoodtarget for ICN control capabilities, they are used in most exampleshere. However, illuminator 111 is simply one type of appliance 101 thatcan be controlled with ICN control capabilities. As shown in FIG. 3,flexible director 123 can be used to control arbitrary entities, such asilluminator 111; controlled power source 102 which supplies power to anarbitrary electrical device through conventional power plug 103;controlled appliance 101, which in this case is shown as a heater;conventional light source 104; and/or other devices incorporating theICN control mechanisms, all of which can receive instructions throughcontrol messages 524. Directors 122 and 123 are examples of thecollective class director (not shown in the figures). Combinedconfigurator/director 151 combines the functions of configurator 141 anddirector 121 in a single component.

Directors 121 are primarily responsible for delivering requests tocontrollers. A director can also deliver new behavior modules 801 tocontrollers and receive reports back about controller operation andabout the device(s) it manages. Directors 121 can range from very simple(e.g., fixed-function director 122, which may be a wall-mounted switchthat only requests illuminators to turn on and off) to relativelysophisticated (e.g., flexible director 123 which is a handheld remotecontrol that can control, configure, and interrogate arbitrarycontrollers 301).

Configurator 141 is typically a graphical software interface run on acommodity computing platform (e.g., desktop PC, laptop, or handheldcomputer) for designing and configuring behaviors. Such an interfaceallows a person to use familiar tools and imagery to specify devicebehavior in a user-friendly manner, and then load the behavior intodirector 121, which can configure controllers 301 to exhibit thatbehavior.

Functions of configurator 141 and director 121 are logically distinct:configurator 141 designs—a relatively rare activity—and director 121controls—something done as a natural part of daily activities. Often,they will be physically distinct: a common implementation would haveconfigurator 141 as software on a desktop or laptop PC, where it wouldcommunicate with a director over USB cable interface 142. The functionsof director 121 and configurator 141 can also be combined as combinedconfigurator/director 151, for instance in a hand-held computer such asPDA that also includes an interface that can communicate withcontrollers 301. A set of controllers 301 forms a local area networkthat may be inherently limited in scope by the type of communicationinterfaces used by controllers 301. Such networks may be connected toeach other, or to the internet, through additional communicationinterfaces and/or gateway elements that transfer data among multiplesuch networks, and/or between ICN networks and other networks.

Part of every controlled appliance 101 in the ICN architecture iscontroller 301. Most types of appliance 101 also incorporate some actualfunction to be controlled, such as illuminator 111 which comprises bothcontroller 301 and light sources. In the limiting case, appliance 101may simply control power delivery to some other entity, as in the caseof controlled power source 102.

2.1 Controller

As shown by the example configuration in FIG. 4, controller 301comprises control microprocessor 401, optionally in combination withsome and/or all of power supplies 411, analog-to-digital converters 421,light sensors 431, sound sensors 441, communication interfaces 501,and/or other interfaces, sensors, actuators, or mechanisms that enablecontroller 301 to interact with its environment, of any of which whichplural instances may included in controller 301. Controller 301 andcontrolled device 321 are supplied with electrical power from externalpower supplies 331. Power supplies 331 may be distinct for controller301 and controlled device 321 as shown in the example, or may beidentical. Power supply 411 serves the conventional function oftransforming externally-supplied power from power supply 331 into theform (a) required by the internal components of controller 301.

Control microprocessor 401 runs software modules called behaviors(section 3 describes a variety of examples) that are loaded intointernal memory of controller 401 and that may be subsequently replaced,updated, and/or adjusted. Behavior modules 801 that are running in acontroller determine both how it responds to requests and what functionsit performs autonomously, for example in response to time-based orsensor input triggers. Controller 301 includes communication interfaces501 that allow it to communicate with directors 121 and with othercontrollers 301 (in other appliances 101 such as illuminators 111).

Controller 301 typically interacts with controlled device 321 throughcontrol signals 351, which provide control inputs to the device.Controller 301 typically monitors status and operation of controlleddevice 321 through status signals 341, which typically are analogvoltages or currents that are converted to digital form throughanalog-to-digital converter(s) 421, although other sensors or interfacesmay be used, including digital interfaces of control microprocessor 401.It will be recognized by those skilled in the art that analog-to-digitalconverter(s) 421 may be integrated with control microprocessor 401, asmay other interfaces and sensors.

Although controller 301 can be used in a stand-alone manner, simplycontrolling power for an arbitrary electrical device, more typicallycontroller 301 is integrated into an other electrical device, such as alight source or appliance. Illuminator device 111 is the integration ofcontroller 301, including appropriate sensors, with an LED light source.Because the ICN architecture is particularly well-adapted to controllinglighting, this description uses illuminator devices to explain andprovide examples of ICN functions.

Controller 301 typically requires a small amount of power to operate,distinct from the power consumed by the device(s) that it controls. Itis often desirable for this power supply to be continuously available,even though external power may be completely disconnected from thecontrolled device. In such cases, controller 301 can incorporate batterypower. Power supply 411 is responsible for converting external AC or DCpower input, and for managing battery power, to voltage levels moresuitable for control microprocessor 401 and other controller components.

Controller 301 is fundamentally a software-controlled device. Controlmicroprocessor 401 controls and monitors the operation of controlleddevices (such as LED emitters 701) based on the behavior softwaremodules 801 that have been loaded into it, and also performscommunication, power management, and device management functions. Itwill be evident that the function of control microprocessor 401 could beperformed by multiple microprocessors, possibly of different types, forexample to allow use of simpler and less microprocessors to perform somesimpler but time-critical functions and using a more powerfulmicroprocessor for the more complex behaviors. Control microprocessor401 incorporates processing capabilities, temporary (operational)storage, and non-volatile storage; it will be evident these elements ofcontrol microprocessor 401 may be integrated in a single semiconductorcomponent (which typically is the most cost-effective approach) or maybe implemented as separate components.

Controller 301 typically incorporates one or more communicationinterfaces 501 for communicating with directors 121 and controllers 301in other system elements. The ICN communication protocols can be carriedover a wide variety of physical interfaces, including infrared,ultrasonic, radio, power line modulation, light modulation, etc.Communication interface 501 typically supports two-way and symmetriccommunication, but a one-way communication such as X10 power-linemodulation, voice recognition, or simple infrared remote control can beused for simple control functions.

Controller 301, particularly when used for controlling a lightingdevice, typically incorporates one or more light sensors 431 formeasuring light intensity. These sensors can be used for feedbackcontrol of lighting intensity based on other ambient illumination (e.g.,daylight) as well as for compensation for changes in light outputintensity. Multiple light sensors 431 may be used for differentpurposes, such as measurement of ambient light, measurement of lightreflected from an illuminated surface, and/or direct measurement of LEDlight output. Light sensors 431 may incorporate spectral filters toallow for measurement of spectral characteristics of LED output.

Controller 301 may incorporate one or more sound sensors 441(microphones). These sensors may be used to enable voice orsound-activated control of the device, as an input to be considered inoccupancy sensing control, and/or as part of an ultrasonic communicationand/or location-mapping function.

Controller 301 may incorporate one or more temperature sensors 451 tomeasure ambient temperature. Temperature sensors can be used to adjustdevice performance or to trigger specific behaviors, such asillumination or blinking to indicate when ambient temperature has goneout of range, and/or delivery of status messages to other systemcomponents.

Controller 301 typically incorporates several voltage-measurementsensors (analog-to-digital converters 421) that allow controlmicroprocessor 401 to monitor relevant aspects of the operation ofappliance 101, such as power consumption and/or LED junction voltagedrop. Junction voltage drop can provide a measurement of junctiontemperature, which in turn can be used for feedback control and lifetimemonitoring.

Controller 301 may incorporate one or more infrared or other types ofmotion sensors 461 (shown in FIG. 5), in order to support controlbehaviors such as occupancy sensing and response. Such sensors cangenerate an electrical signal that it is interpreted by the controlmicroprocessor to identify potential motion.

Controller 301 may incorporate one or more video/image sensors(connected similarly to motion sensors 461) that can be used to supportbehaviors such as occupancy sensing and response. Such sensors cangenerate pixel image that is processed and interpreted by controlmicroprocessor 401 to identify potential motion. An image sensor couldinclude optics such as a fish-eye lens to allow coverage of the fullfield visible from the device.

2.2 LED Illuminator

FIG. 5 shows an example implementation of LED illuminator 111. Itincorporates plural LEDs 701, which may emit different colors and/orinclude different phosphors to produce different color distributions.LEDs 701 may be all the same (e.g., white LEDs using phosphortechnology), multi-color for mixing applications (e.g., red/green/blueor red/blue/green/amber), or predominantly white with additional colors(e.g., red, green) to mix for small adjustments to color fidelity and/orcolor temperature.

LEDs 701 are mounted on thermally dissipative mounting substrate 721,which conducts generated heat away from the LEDs and reduces theirjunction temperature. Heat transfer is preferably passive (e.g., throughconvection or by conduction to the illuminator housing, heatsinks, heatpipes), although active heat removal (e.g., fans, piezoelectric airmovers) may also be employed.

LEDs 701 produce light output that is filtered through optical diffuser731, which produces a uniform beam output by mixing and diffusing theoutputs of individual LEDs 701. Because the output patterns of LEDs aredirectional, illuminator 111 typically contains reflector and/ordiffuser assemblies to combine the output of the LEDs and provide a moreuniform appearance. Mixing and uniformity can be particularly beneficialwhen combining LEDs with different color outputs as opposed to combiningoutputs from multiple LEDs with similar color spectra, although in someapplications (for example, reflected rather than direct lighting) anexplicit optical mixing component may not be required. Optical diffuser731 can also form the light output into a more desirable beam patternthat may differ from the native output pattern of the LEDs.

LEDs 701 are individually controlled by metal-oxide-semiconductorfield-effect transistor (MOSFET) switches 711, which are connected toshunt the current passing through each LED to turn the LED off in theMOSFET's low-resistance state, or to allow the LED to illuminate in theMOSFET's high-resistance state. LED control signals 741 driven bycontrol microprocessor 401 determine the state of the LEDs. Thesecontrol signals may be modulated very rapidly using pulse-widthmodulation or similar techniques to achieve intensity and color control.LED power supply 421 provides constant-current DC power to operate theLEDs. Power control signals 742 driven by control microprocessor 401determine the current level and operating state of power supply 421(which may be turned completely off when no illumination is desired, toreduce system power dissipation to a minimum level. Analog-to-digitalconverter 421 can be used to monitor forward voltage drop of LEDs 701,to allow accurate inference of LED junction temperature in support ofintensity and spectrum control, as well as lifetime prediction andidentification of failed components. Analog-to-digital converter 421 canalso be used to monitor system power consumption for energy usage statusreporting. Light sensor 431, sound sensor 441, temperature sensor 451,and motion sensor 461 can be used to provide inputs for intensitymanagement, occupancy sensing, and other control functions.Communication interface(s) 501 enable controller 301 to communicate withother controllers. Not shown in FIG. 5, but evident to one skilled inthe art, is that power supply 411 and power supply 741 would suppliedfrom external power source 331, and could be combined in a singlecomponent if convenient.

Power supply 741 converts available power from one or more externalpower sources (e.g., AC line current, low-voltage DC supply, batterypower) into the current-regulated or limited voltages required by theLED emitters. Power supply 741 may incorporate both a power conversionfunction and an LED control function (e.g., switching the MOSFETs 711),the former function being responsible for converting raw input power tomore easily manageable (e.g., DC, lower-voltage) form, and the latterfunction providing adjustable output current and/or the ability tomodulate the output with pulse width or other techniques. In anilluminator with several LED emitters, power supply 741 may producemultiple independent current-regulated outputs for powering largernumbers of LEDs 701 than is practical from a single output. Multipleoutputs may provide also greater failure tolerance and redundancy.

Depending on the intended application, illuminator 111 is typicallydesigned to provide light with specific color characteristics. Sometimesit is desirable for color characteristics to be adjustable, but in othercases fixed output is acceptable. The simplest is the fixed white color:using phosphor-based warm white or cool white LEDs, such an illuminatorproduces a single color spectrum of white light output. The intensity,but not the color, of such a source may be adjusted. A moresophisticated type of illuminator 111 may employ a mix, primarily ofwhite LEDs and a limited number of color, to allow the color spectrum tobe adjusted dynamically (e.g., switching between the warm white producedby incandescent sources and the cool white characteristic of daylight.Finally, illuminator 111 may be designed to produce any color throughuse of multiple colored LEDs and color mixing. Combinations such asred/green/blue or red/green/blue/amber are frequently employed; the morecolors that are available, the greater the variety of high-qualitycolors that can be produced.

Although LEDs are a particularly effective light source, it is alsopossible to control other light sources with essentially the samearchitecture as the LED-based illuminator shown in FIG. 5. For example,the controller function of an illuminator could be combined with anycombination of LED, incandescent, fluorescent, high-intensity discharge,or other light sources. The functions of controller 301 can also bepackaged separately and used to control power for arbitrary otherdevices including, for example, stand alone lamps or appliances.

2.3 Director

Director 121 is used to send requests to one or more controllers 301,deliver behavior modules 801 to controllers 301, and/or to receivestatus reports from controllers 301. In concept (and often inappearance), director 121 is quite similar to a conventional infraredremote control such as might be used with a television set. However,unlike such controls, which only transmit signals and do not receivethem, director 121 typically uses a two-way communication protocol tointeract with controllers 301 and other directors 121, just ascontrollers 301 do to interact with each other. This two-way protocoluses acknowledgments and retransmission to allow the director to performmore reliably, and to perform more sophisticated functions, than aconventional remote control. Colloquially speaking, the purpose ofdirector 121 is to request specific functions from controlled appliances101.

Typically, director 121 includes a control microprocessor, at least onecommunication interface (e.g., infrared, ultrasonic), and one or morehuman operator interfaces (e.g., buttons, knobs, switches). Director 121may also include a display to allow the operator to view the response toa request and/or to review and/or observe details of a request. Theexamples described herein are based around two types of director, thesimple fixed-function director 122 and the more powerful andsophisticated flexible director 123. It will be evident to one skilledin the art that these distinctions are arbitrary, and that the functionsthat might be performed by director 121 can be packaged in a virtuallylimitless variety of packages and configurations (including the combinedconfiguration of configurator/director 151). The two examples here areillustrative, not constraining.

Fixed-function director 122 is very simple, typically used as a“lightswitch replacement”. As shown in FIG. 6A, one embodiment offixed-function director 122 consists of plural operator interfacebuttons 132, used to indicate the intended function, connected tomicrocontroller 131. Communication with controllers 301 is provided, inthis embodiment, through an infrared link with a communication interfaceconsisting of infrared transmitted 133 (typically an infrared LED) andinfrared receiver 134 (typically a photodiode). Battery 135 providesoperating power.

Fixed function-director 122 would often be wall-mounted, although it canbe placed in other housings and does not require a fixed mounting. Asoperator input interfaces, it has one or more switches or sliders thatmimic the appearance and operation of a conventional light switch ordimmer switch. Fixed-function director 122 would typically beprogrammed, by some configurator 141 or by direct interaction with someilluminator 111, to interact with a designated illuminator 111 or groupof illuminators 111, as its intended purpose is to provide the samecapabilities as a conventional lightswitch: direct control of specificlighting sources. A difference between fixed-function director 122 and astandard lightswitch is that fixed-function director 122 does notrequire any dedicated wiring to connect it to the devices (e.g.,illuminators 111) that it controls, since it uses an ICN wirelesscommunication interface, and that it can be reprogrammed to alter theassociation it has with designated devices illuminators, or evenreprogrammed to change its basic functions.

Fixed-function director 122 may use a one-way (unacknowledged)communication protocol to communicate with controllers 301, since thereis typically direct feedback to the operator about whether the messagewas delivered, and the request can be repeated easily by the operator(e.g., if the lights do not illuminate, press the “on” button again).One reason to use a one-way communication protocol is to minimize energyconsumption by fixed-function director 122. A low-power implementationcould use a long-life lithium battery, consuming little enough currentthat the battery would discharge no more rapidly than with no load atall.

Alternatively, as shown in FIG. 6B, an alternate embodiment forlow-power implementation could use photovoltaic conversion (of ambientlight) to store sufficient energy to send a small number of messages.This embodiment consists of plural operator interface buttons 132,microcontroller 131, infrared transmitter 133 and infrared receiver 134,but substitutes photovoltaic cell 135, charge control circuitry 137, andstorage capacitor 138 for battery 135 used in FIG. 6A. Ambient lightstrikes the photovoltaic cell, producing voltage that is routed throughcharge control circuit 137 to capacitor 138. Charge control circuit 137(for example, a Texas Instruments TPS61200 converter) converts thephotovoltaic voltage to a level suitable for operating microcontroller131 and stores it in capacitor 138.

A further alternate embodiment could use electromagnetic generationpowered by the mechanical operation of the control input to the unit:moving a switch can generate enough power to generate the requiredmessage. The availability of ultra-low power microcontrollers such asthe MSP430 series from Texas Instruments makes such low-power approachesplausible.

Fixed-function director 122 can also be connected directly to theexternal power source, and communicate with radiofrequency modulationover the power line.

Another type of director 121 is flexible director 123, shown in FIG. 7.This device is physically similar to a sophisticated handheld remotecontrol: it may includes multiple buttons and/or knobs for its operatorinterface shown as keypad 124. It typically also includes display 125 toallow the operator to see responses send in return to requests byflexible director 123. Its communication interface is typically capableof operating directionally so that the operator can point it at aspecific illuminator 111 to direct requests to that illuminator alone(which, of course, may forward the request to other illuminators in agroup or groups). Control microprocessor 131 in flexible director 123typically has sufficient memory both for the director's own software andfor storing behavior modules 801 to be delivered to illuminators.Flexible director 123 typically also includes USB interface 139 or othercomputer-oriented interface to allow it to be updated by configurator141. Other components in flexible director 123 (infrared transmitter133, infrared receiver 134, battery 135) serve the same purpose as infixed-function director 122. An alternative embodiment of flexibledirector 123 employs a handheld computer equipped with appropriateinfrared transmitter 133 and infrared receiver 134 perhiperals andappropriate operating software.

2.4 Configurator

Configurator 141 is a software application, running on some hardwareplatform, that is used to design behaviors. It provides a rich,user-focused graphical interface that allows the user to describe thedesired behavior of a set of controllers 301 (e.g., those contained inilluminators 111).

After designing the behaviors with configurator 141, the user thentypically transfers the resulting behavior modules 801 into someflexible director 123. Flexible director 123 can then be used to deliverthe specified behaviors to some controller 301, which would then, asappropriate, use its communication interface to ensure that the behaviormodules 801 are delivered to all controllers 301 that require them.

The ICN architecture explicitly allows the functions of configurator 141and director 121 to be implemented independently, because thatcorresponds to a common usage model: an operator could use the powerfulgraphical interface of configurator 141 running on a personal computerto design or adjust lighting behaviors for a space, but that task wouldtypically be performed rarely. In normal operation, minor behavioradjustments and explicit light settings could be performed with a moreconvenient flexible director 123 device.

However, in some applications, it is more appropriate to combine thefunctions of director 121 and configurator 141. For example, an operatormanaging an entire building's lighting, or obtaining status informationfor a large area, may use a combined configurator/director 151 unit,which could be portable (such as a Tablet PC or Palm Pilot device) or ina fixed location. In such applications, additional communication gatewaycomponents might be employed, for example using standard network, wired,or wireless communication from the operator's computer system to reach acommunication gateway component 161 in the areas where targetedcontrollers 301 are present. Such gateway components could beparticularly helpful when an existing building management system (e.g.,based on the ZigBee or LONWorks protocols) is present; alternatively, itis possible to build controllers that incorporate those communicationinterfaces directly and to use them the communication among ICNcomponents.

It will be evident that although a graphical interface for configurator141 may be desirable to optimize the interface for ease of use, otherinterfaces for specifying behaviors and parameters may also be employed.For example, a scripting or other computer language may employ keywords,variables, values, and other common computer language elements tospecify configurations, and in fact multiple different computerlanguages could be employed in different applications or together in asingle application. Multiple different graphical interfaces may also beemployed for different applications or in combination with each other orwith language-based interfaces. Graphical and other interface techniquesprovide a wide variety of ways to approach interface designs.

3 Illuminator Behaviors

Because it is a software-controlled device, illuminator 111 can beprogrammed to perform a wide variety of functions. A variety of suchfunctions is described below, using illuminator 111 as the exampleembodiment. It is understood that activities attributed to illuminator111 are in fact carried out by the controller 301 component ofilluminator 111, employing software running on control microprocessor401 component of controller 301.

It will be evident that many of these behavior functions are alsoapplicable controllers that operate non-LED or non-lighting devices, butas LED lighting provides a particularly rich scope for defining usefulbehaviors, all the examples in this section are described in terms ofLED-based illuminators.

3.1 Direct Control

Illuminator 111 may respond to requests (e.g., from director 121) thatinstruct it to perform specific functions. A typical set of directrequests accepted by illuminator 111 could include:

-   -   “on”—Turn the light source on    -   “off”—Turn the light source off    -   “set level XX %”—Set the intensity of the light source to the        specified value    -   “brighter XX %”—Increase the light source intensity by specified        increment    -   “dimmer XX %”—Decrease the light source intensity by specified        increment

Many additional requests may be accepted, depending on the capabilitiesof illuminator 111 and director 121. Additional requests would be usedto enable capabilities discussed further below.

Direct requests may be combined in a single request message. Forexample, a request might combine “on” and “set level 100%” to turn onthe light at maximum intensity.

Brightness may be adjusted using pulse-width modulation or relatedtechniques. Brightness may also be adjusted by changing the currentdelivered by LED power supply 741. Reduced current increases LEDlifetime and reduced junction temperature, but it may also cause colorshifts in LED output which would require compensation in order tomaintain uniform color.

3.2 Group Control

Illuminator 111 may be part of a group of illuminators that all areintended to respond similarly. To accomplish this, communicationinterface 501 can be used to pass on the requests from one illuminatorto others, until all members of the group have been informed of therequest. To ensure reliable transfer, positive acknowledgement wouldtypically be part of such a communication protocol.

The simplest application of group control is to have all theilluminators in a group respond to direct control requests. However,group control assists in providing many of the other behavior functionswhen multiple illuminators are involved, as it allows illuminators tocooperate in exhibiting similar behaviors.

Illuminator 111 can be manually assigned to groups using director 121.The director can instruct a given illuminator 111 that it is to belongto a designated group or groups or, alternatively, that it no longerbelongs to a designated group or groups.

Preferably, illuminators 111 can associate into groups autonomously,based on the ability to communicate with each other, using conventionaldistributed processing algorithms. Since the preferred mechanisms (e.g.,infrared, ultrasound) for communication interface 501 are generallylocalized to a single open (that is, they are blocked by walls anddoors), the illuminators in such an area can identify themselves to eachother and form a group based on reachability.

Illuminator 111 can adjust the intensity or strength of itscommunication transmissions, and/or the sensitivity of its communicationreceiver, to dynamically adjust the distance over which group detectiontakes place. For example, a newly-installed illuminator could start atlow communication power/sensitivity to locate nearby neighbors, andincrementally increase its communication range to larger areas to obtaina more complete picture of its neighbors.

Autonomous group membership determination will typically take place whena set of illuminators is installed and powered on for the first time. Toensure that group membership is determined in an orderly manner, theilluminators can implement group membership and quorum protocols of thesort commonly used in distributed computing systems.

Each illuminator 111 can belong to multiple groups, allowing requestsreceived by a particular illuminator to have different scope dependingon the group or groups to which they are addressed.

Because different illuminators can have plural communication interfaces,the scope of a group can extend beyond that of a particularcommunication mechanism. An installation may also include explicitgateway 161 components that use additional physical communicationmechanisms to transfer communication messages across boundaries (e.g.,through walls or floors) that would otherwise not be reachable. Forexample, in a large building, all the illuminators 111 might belong to asingle “maintenance” group, used to collect status information, eventhough ordinary functions (such as direct control) would typically beprocessed only within smaller groups (such as all the illuminators in aparticular office space).

3.3 Timed Control

Illuminators 111 can keep track of the date and time of day and exhibitbehaviors triggered at specific times. For example, an illuminator (orgroup of illuminators) can be requested to turn on at the beginning ofthe business day and off at the end of the day. As another example, amore sophisticated time-based behavior would be to emulate sunrise(i.e., become gradually brighter over a period of an hour) to provide agentle wakening experience.

Illuminators 111 can be informed of the current date and time bydirector 121. Director 121 can similarly be informed of the time byconfigurator 141, which can obtain accurate highly accurate time fromnetwork time references, for example by using the Network Time Protocol(NTP) or the Simple Network Time Protocol (SNTP).

Illuminator 111 (if connected to an AC power supply) can be keptsynchronized with correct time by counting cycles in the supply current.Because the frequency of the AC power line is typically very accuratelycontrolled, it can be used to maintain an accurate time once the timehas been initialized.

When not connected to an AC power supply, or if an AC power supply isinterrupted, illuminator 111 can maintain an internal time referenceusing a crystal oscillator connected to control microprocessor 401, orother accurate timing reference, perhaps integrated to controlmicroprocessor 401. In such circumstances, controller 301 wouldtypically be powered by a backup power source such as a capacitor orbackup battery. Controller 301 would typically set itself to operatewith reduced power consumption (e.g., by enabling a low-power operatingmode of control microprocessor 401), as many controller functions wouldnot be meaningful if there is no power available for the rest of thedevice.

Less accurate time can be maintained by using the internal clock ofcontrol microprocessor 401. The actual frequency of the internal clockcan be estimated by applying a temperature-based correction calculationbased on a temperature determined by temperature sensor 451 or by theforward voltage drop of one of LEDs 701. If an ultra-low powermicrocontroller is used, the internal oscillator or an external crystalcan be operated for a long period from the charge in a capacitor, whichcan be replenished when external power (e.g., the AC line) next becomesavailable (e.g., after a failure and restoration of utility power).Often, the less accurate time determined by the internal oscillator issufficiently accurate for lighting control purposes, particularlybecause it can be adjusted to a more correct through interaction with adirector or another illuminator.

Time-based behaviors will often differ based on the day of the week andholidays or other special occasions. Configurator 151 can be used todefine such patterns and times, and to communicate them to a directorfor delivery to illuminators 111

3.4 Control-Based Learning

Illuminator 111 can record the requests it has been given and repeatthem at a later time, for example allowing it to learn desired on/offtimes on one day and repeating them on subsequent days.

Such learning could, for example, be adjusted by knowledge of specificdays, weekends, and holidays, allowing repetition of desired behavior onappropriate days, for example mimicking a week's use of lighting.

Illuminator 111 could learn multiple distinct patterns of use, whichcould then be selected with director 111, allowing for example easydesignation of “holiday” usage patterns by a human operator without thenecessity of keeping track of specific holidays internally.

Such learning could, for example, be adjusted to accommodate temporarychanges. For example, illuminator 111 could learn an average pattern ofbehavior by combining and averaging requests received over multipledays, so that temporary adjustments would not immediately change thelearned average pattern on subsequent days. Director 121 could beequipped with an interface to designate any particular change as“permanent” (i.e., to be incorporated in the learned pattern ofbehavior) or “temporary” (i.e., to leave the learned behavior patternunchanged).

Such learning could, for example, be configured to make small randomadjustments to the pattern of usage and thus to provide a more realisticappearance of occupancy.

Such learned behavior could, for example, be coordinated across groupsof illuminators, so that all the control changes for a group take placesimultaneously, as they would for an explicitly requested change.

3.5 Ambient Illumination Response

Illuminator 111 can incorporate light sensor 431 to measure the lightreflected from the field illuminated by illuminator 111. By sampling thelight intensity returned under different conditions of illumination, theilluminator can determine how much light is being provided by othersources. For example, illuminator 111 can, for a brief period (e.g.,milliseconds) reduce its brightness by a known amount or shut offentirely and measure the reflected light during that interval. Becausethe interval is so short, the change would not be perceptible to humanobservers.

Ambient light measurement allows illuminator 111 to reduce or eliminateits own output (thus reducing energy consumption) whenever sufficientother light (e.g., daylight, sunlight) is present to provide the desiredlevel of illumination. The desired level could, for example, be setexplicitly using director 121, or can be learned by manually setting thebrightness to an acceptable level and then indicating that as thedesired target level using director 121.

Ambient light measurement and response can be coordinated across a groupof illuminators 111 to ensure that each one's field is sufficientlyilluminated, even though that may require different brightness levelsfrom individual illuminators.

The measurements can be coordinated through use of a synchronizationprotocol so that other illuminators are dark while each one measures itsown contribution. Coordination of such measurements can be achievedthrough communication interface 501, by establishing specific windowsduring which measurements are made. Such measurement windows would needto be closely synchronized, which can be accomplished with a dynamicallyconverging interaction process.

Ambient light adjustment is useful both on long and short time scales.For example, a long time scale could compensate for sunlight changesduring the course of an entire day. A shorter time scale couldcompensate for sunlight changes caused by cloud movements or even bypassing aircraft. For such shorter time scales, it is particularlyuseful to be able to make individual light intensity measurementsrapidly, and to adjust individual illuminators independently, whichmotivates the use of a separate light sensor 431 in each illuminator111, rather than for the system as a whole as is conventionally donewith sun sensors. Another motivation for individual sensors is that therelative amounts of sunlight in different parts of a space will differwith the angle and position of the sun. Thus, some locations may requiremore added light because the sun is blocked by another building.

3.6 Occupancy Response

Illuminator 111 can incorporate sensors to detect presence of humanoccupants, enabling it to reduce energy consumption by providing lightonly when needed. If the sensor(s) detect(s) no indication of occupancyfor an extended period, the light output can be turned off or decreasedin brightness. Light output can be decreased gradually to minimizedisturbance.

For example, motion sensor 461 can be a conventional long-wave infraredmotion sensor can be used for detecting motion of warm bodies. Controlmicroprocessor 401 can monitor and integrate the output of motion sensor461 over a relatively long period to avoid accidentally turning offlights while someone is present.

Sound sensor 451 (e.g., a microphone) can also be used for occupancydetection. Control microprocessor 401 can perform signal processing toallow illuminator 111 to ignore repetitive or constant sound (e.g.,fans, machines) and to give preference to less regular sounds, such ashuman conversation, as an indicator of occupancy. In an environmentwhere multiple illuminators 111 equipped with sound sensors 451, theinputs from the different sensors can be analyzed together, ascoordinated through communication interfaces 501, to provide moreaccurate recognition of occupant-generated sounds even in the presenceof other sounds.

Motion sensor 461 can also be a video image sensor. Controlmicroprocessor 401 can monitor the video image for movement and makedecisions about probable occupancy based on the amount of change in thescene being viewed. A fisheye lens can be used to provide a full 180degree field of view for such a sensor, since the fidelity of the imageto a human-familiar viewpoint is of secondary importance to simpledetection of motion and/or patterns.

One illuminator 111, or group of illuminators 111, incorporating suchvideo image sensors can be configured to ignore movement in some areasof the image, so as to prevent detection of occupancy based, forexample, on motion visible through an exterior window. Suchconfiguration can be established interactively, for example using ahandheld director 121 to indicate that location where the director iscurrently being used should not be considered in occupancy detection. Ahuman operator could, for example, stand in front of a window and movedirector 121 around to indicate that the window is an area not to beconsidered.

A video image motion sensor 461 can be used to provide more preciserecognition of motion and appropriate responses. For example, ratherthan needing to conclude that a room is unoccupied based on a lack ofsignals from a simple long-wave infrared motion sensor, a video imagesensor can be used to recognize when a human leaves a room. Although thegeneral problem of understanding occupant motion is an open researchtopic in computer vision, particularly when multiple people may beinvolved, it is much simpler to recognize an image of a single personexiting from a single-occupancy space such as a closet or bathroom.

A video image motion detector sensor 461 can be used to recognizenatural gestures that affect lighting behavior parameters. For example,a repeated upward hand motion can be recognized and interpreted to meanthat more light is desired, particularly if it is recognized shortlyafter an illuminator has decreased available lighting.

Typically, if multiple sensors are present (e.g., sound sensor 451 andmotion sensor 461), illuminator 111 would combine signals andsignal-derived conclusions from the different sensors to provide a morereliable overall detection of occupancy.

Illuminator 111 can, for example, make a perceptible signal, such as abrief blink or dimming of the light, and/or an audible sound and/or asynthesized voice, prior to turning off light output. Such a signalenables room occupants to respond in a way that indicates a desire forcontinued illumination. Illuminator 111 can also increase thesensitivity of its detection algorithms following such a signal, so thateven a slight subconscious reaction from an occupant could be detected.Thus, even when a single person is alert but essentially motionless inthe illuminated space, a low-level signal and slight reaction can besufficient to maintain illumination. The intensity of the signal andsensitivity of the detection can be increased several times beforeturning off the light.

Perceptible responses from illuminator 111 may be employed in a varietyof other circumstances, such as responding to voice commands orconfiguration instructions. Synthesized voice response in particular cancontribute significantly to ease-of-use when configuring and adjustingilluminators.

Rather than a discrete signal to indicate impending darkness, the lightcan be gradually dimmed as the sensors continue not to indicateoccupancy, and then brightened as occupancy is detected. This behaviorcan be configured to be subtle and below the normal threshold ofperception.

Multiple illuminators 111 in a single space can coordinate theiroccupancy detection responses and achieve more accurate results thanwould be possible with the single sensor that is often used intraditional implementations. For example, occupancy detected by any ofthe illuminators in a conference room could result in maintainingillumination throughout the room. Because the motion sensors 461 “see”essentially the same field that the LEDs illuminate, such coordinationensures that any occupant who can see with the light can also be seen.

3.7 Building System Integration

The distributed nature of controllers 301 and associated sensors in anICN installation can improve operation of other building systems byproviding inputs that are more accurate, more responsive, and/orfiner-grained than those provided by the native sensors and inputs insuch systems.

For example, the occupancy detection mechanisms discussed above can beintegrated with other building systems, for example providing input tocontrols for heaving, ventilation, and air conditioning (HVAC) systems.In such applications, when the ICN system determines that a space isunoccupied, it can so advise the building HVAC system (e.g., through itscommunication interface 501 and a gateway 161 that is connected to thebuilding management system), which can respond by adjusting temperatureand related set-points. The distributed nature of the ICN sensors acrossmultiple illuminators 111 can make it possible for the ICN devices toreach a more accurate conclusion about occupancy than is possible forthe smaller number of sensors typically employed in a typicaloccupancy-responsive HVAC system.

As another example, other building systems can be integrated with ICNoccupancy detection, such as those that control automated blinds orwindow covers, those that enable building security controls, etc.

Depending on the nature of the building control systems, an ICNinstallation can be integrated so that it directly specifies the desiredresults (e.g., by directly adjusting a thermostat through an electricalremote control input) or so that it simply provides advisory input tothe building system(s), for example by a network connection (implementedwith a gateway 161 component) to a building control system.

Integration can take place at less sophisticated levels, as well. Forexample, a very simple integration would be for illuminator 111 toprovide direct control inputs to other devices, such as controllinglights that are not otherwise part of the ICN system but that mirror thestatus of that illuminator (or a set of illuminators). Such integrationcan, for example, be implemented through traditional control systemssuch as X10, where controller 301 produces such control signals asoutput. Such integration can also be implemented as direct electricaloutputs from a controller, or at a higher level of abstraction throughmore sophisticated network protocols invoked through an ICN networkand/or a gateway component.

3.8 Voice Response

Illuminator 301 can incorporate sound sensor 451 (e.g., a microphone)and voice recognition software in control microprocessor 401 to allow itto respond to voice requests. Limited-vocabulary voice recognitionsoftware is widely available commercially, and is used in applicationssuch as interactive toys and hands-free telephones.

A “trigger phrase” can be used to reduce the likelihood of spontaneousand unintended recognition.

Response to voice requests can be coordinated across groups ofilluminators 111 just as are other types of control requests.

Voice recognition can be coordinated across plural illuminators 111 toensure more accurate results, for example by selecting the severalilluminators exhibiting the highest confidence recognitions for aparticular request, and ensuring that all those are in fact recognizingthe same request. In such a embodiment, each illuminator that recognizesa voice request could broadcast a message to other neighboringilluminators requesting that they respond with an indication of whetherthey recognized the same voice request. Using conventional distributedcomputing techniques, the illuminators can coordinate their jointknowledge of voice requests and reach consensus on what, if any, actionshould be taken.

Sounds other than voice can also be recognized. For example, to assistpeople with hearing disabilities, illuminator 111 could be configured totranslate ambient sounds such as telephone rings or smoke alarms tomodulations of light intensity or color. Such capabilities areconventionally provided by auxiliary devices, but could be integratedinto an ICN installation simply through installation of additionalbehavior software modules 801.

3.9 Redundancy and Failure Response

Output reduction due to aging as well as outright component failure aresignificant issues for LEDs.

To ensure a long effective lifetime for illuminator 111, additional LEDs701 can be incorporated along with software in control microprocessor401 that allows constant output to be maintained even as aging orfailures occur.

Control microprocessor 401 can adjust drive current provided by powersupply 741 as the LEDs age to increase light output. Additionally, ifLEDs 701 are not operated at 100% duty cycle at the beginning of theilluminator's life, controller 301 can increase the pulse widthmodulation duty cycle to increase effective output.

Additionally, control microprocessor 401 can enable use of redundant(spare) LEDs that were not used at all initially. Enabling spare LEDsallows the illuminator both to maintain output over time (by addingadditional LEDs and, as needed, reducing the drive current and/ormodulation) and to tolerate LED failures by simply switching in areplacement LED.

The output of LEDs 701 can be measured directly, by a light sensor 431coupled to a particular LED or LEDs to determine the need to increaseoutput. Additionally, light output can be measured indirectly, byobserving the differences in ambient light produced at different levelsof (including zero) of drive current. Light output can also be modeledbased on the LED manufacturer's specified aging properties.

Measuring LED output by examining the effect on ambient light intensity(e.g., from a light sensor 431 not coupled to LED(s) in the illuminator)will typically depend on the reflectivity of the objects and surfacesilluminated by the LED. Because that reflectivity may change over time(e.g., objects may be moved, surfaces may be covered), such measurementsmay require careful long-term monitoring of changes in the environmentand recalibration of the factors used to estimate LED brightness fromthe measured light intensity at light sensor 431. Because LEDs typicallyage in a relatively slow and predictable manner, even though thelight-to-age relationship for any particular LED may differ from others,it will generally be practical to distinguish between the rapid changesin reflectivity caused by human activity and the slow changes inbrightness caused by aging.

Aging also potentially affects color spectrum. Control microprocessor401 can compensate for this effect based either on color-sensitivesensor inputs or a model of aging-related color performance.

When controlling a non-LED light source, it may be impractical tomonitor individual light sources (e.g., light bulbs), or to bring inreplacement sources automatically. However, even in such applications,controller 301 can monitor power consumption to detect when one of theseveral bulbs in a device has failed, and in some cases (e.g.,fluorescent bulbs) may be able to detect power consumption patterns(e.g., slow start) that indicate a failure will occur soon. In suchcases, controller 301 may choose to reduce the maximum permittedbrightness to increase the likely lifetime of remaining bulbs (at leastuntil replacement).

Information about failures and potential failures can be used in avariety of ways, depending on the configured behaviors. Informationabout aging or failure can be used to alter operation of illuminator 111where the information is obtained, for instance by changing brightnesslevels or enabling redundant light sources. Additionally, suchinformation can be used to drive requests to neighboring illuminators tocompensate for changes in one illuminator. Also, it can be delivered asa status report, for example on demand to a human operator orautomatically to a building management system.

3.10 Temperature-Based Feedback

As junction temperature increases, an LED light output typicallydecreases, and its emitted spectrum shifts.

Control microprocessor 401 can compensate for changes in light output bymeasuring junction temperature and adjusting drive current and/ormodulation.

Control microprocessor 401 can compensate for changes in color spectrumby measuring junction temperature and adjusting the drive current and/ormodulation for other LEDs 701 (which have different output spectra) inthe illuminator that influence the overall blended color.

Junction temperature can be measured indirectly by measuring the forwardvoltage drop of LED 701, using analog-to-digital converter 421. Becauseof basic semiconductor physics, junction temperature varies predictablywith temperature. However, because forward voltage drop also is affectedby random variations in manufacturing, it may be necessary to measurethe forward voltage drop at one or two reference temperatures prior orduring manufacture of illuminator 111, but once those parameters arestored by control microprocessor 401, it can use them to calculatejunction temperature while the illuminator is operating.

Junction temperature can also be measured directly by a temperaturesensor 451 (e.g., a semiconductor temperature sensor of thermocouple).However, it can be difficult to get an accurate measurement for thejunction itself, because it may be infeasible to place temperaturesensor 451 in sufficiently close proximity to the junction of LED 701 toget an accurate reading of temperature.

In addition, measurement of ambient temperature can be incorporated intothe integration of ICN controllers 301 with other building controlsystems, such as HVAC, to provide a more accurate picture of temperaturedistributions in a building than may be readily available to the HVACsystem itself.

3.11 Status Reporting

Illuminator 111 can measure and/or calculate a variety ofcharacteristics about its operation including effects of LED aging andcompensatory action, actual power consumption, ambient illumination andapparent light output, total operating hours, LED temperature, AC linepower quality, etc. Such status information can be accumulated bycontrol microprocessor 401 and reported back to configurator 141 orother destination through director 121 or gateway 161. Such statusinformation can also be communicated directly to a director 121.

One application of such reporting is to allow failures to be tracked andpredicted, so that maintenance can be conveniently scheduled, and alsoto monitor correct operation of the illuminator.

To identify a particular illuminator 111 for purposes of interpretingreported status information, each illuminator can be assigned anidentifier at the time it is installed; additionally, this identifiercan be subsequently updated. An illuminator 111 may have multipleidentifiers used for different purposes, such as one that identifiesphysical location and one that associates it with an activity performedin an area. Identifiers can have multiple parts, such as identifying abuilding, a floor within the building, a room location, and anidentifier for different illuminators 111 within that room. Multi-partidentifiers can be used to define group membership.

Identifiers can be assigned manually, for example by entering a numericvalue on the keypad of a director and instructing a particularilluminator to adopt that identifier. Alternatively, identifiers can beassigned semi-automatically, by instructing them in turn with a directorthat assigns sequential identifiers. Identifiers can be assignedautomatically by allowing the illuminators 111 in an area to interactsuch that each illuminator is assigned a different identifier. Automaticassignment can take place implicitly as a side-effect of theinstallation process, or when instructed by director 121. In the case ofmulti-part identifiers, director 121 can be used to assign explicitlythat part of the identifier that is common to all illuminators in anarea by instructing a single illuminator to establish that common part,and another technique can be used to assign the other part of theidentifiers.

Director 121 can be used to interrogate an illuminator for itsidentifier, allowing, for example, automatically assigned identifiers tobe obtained and recorded on a map or floorplan.

3.12 Location Identification

For status reporting, it is often helpful to know the physical locationof each illuminator 111, so that an illuminator requiring maintenancecan be easily found in the physical world.

One approach to identifying locations is to place them explicitly on amap by interaction with director 121. A human traveling through anilluminated space can interrogate each illuminator 111 in turn with adirector 121 that can record the illuminator's physical location in aninternal database. Physical location can be determined by a directorthat is equipped with or connected to a Global Positioning System (GPS)device and/or other location-determination technology (e.g., an indoorlocation system based on broadcast television signals, wireless hotspotsignals, or even an inertial-assisted GPS location technology).Alternatively, physical location can be explicitly recorded against amap or other representation of the space displayed by director 121. Insuch manual detection modes, each illuminator 111 can remember whetherits position has been recorded and make that information globallyavailable, allowing the human operator to be reminded if there are anyremaining positions to record before leaving the area.

Alternatively, the illuminators 111 can incorporate measurementtechnology allowing them to determine their own locations. An ultrasonictransducer, which may also be used as communication interface 501 tocarry the communication protocol, can measure relative distances betweenilluminators. Distance measurement by ultrasound is relatively easy,since the speed of sound allows high-precision measurement of distancewith simple hardware. Distance measurement can also be performed bymeasuring delays or phase shifts in an infrared transmission, but moresophisticated techniques are required because the delays are so muchshorter. Because many of the inter-illuminator paths for ultrasonic andinfrared communication will involve reflection, geometric analysis maybe required across all the measurements in an area to translate themeasured path delays into actual physical locations. However, becauseilluminators rarely move (particularly when permanently installed),measurements may be taken over a long period and analyzed with digitalsignal processing techniques to obtain additional information.

When location identification is performed, each illuminator 111 can alsobe informed of its position, and provide its location rather than justits identifier, when reporting status information.

3.13 Location-Adaptive Control

In combination with location identification and awareness, a set ofilluminators 111 can cooperate to provide a balanced adjustment of lightintensities and colors in response to a request directed at a singleilluminator. Similarly, autonomous control behaviors may, throughcommunication among illuminators, provide a lighting experience moreclosely adapted to human needs.

For example, when a single worker in a large office space requests morelight or a change in the light's coloration, by directing that requestto a single overhead illuminator 111, if only that illuminator responds,it will be a clearly visible non-uniformity in the overall pattern oflight delivered to the large space. If many workers make suchadjustments, the overall lighting pattern can become very ragged andaesthetically unappealing. By using the knowledge of illuminatorlocation, the illuminator receiving the request can also ensure thatother nearby illuminators participate in the requested change but to alesser degree, so that the overall pattern of light is maintained in amore uniform, smoothly varying fashion. Using conventional distributedprocessing techniques and knowledge of illuminator location,illuminators can construct a map of the light intensities of all theilluminators in a neighborhood, and adjust their brightness levels toensure a smooth lighting gradient.

As another example, if a person is walking through a corridor in adarkened area, illuminators 111 that detect the pattern of progress(through their motion sensors 461) can arrange for illumination in otherareas, in advance of the person's anticipated arrival. This can beparticularly advantageous for outdoor lighting, where it is desirable tolight an entire pathway when a person is going to travel along the path.

3.14 Adjustable and Learned Response

Parameters governing behavior response may be selected from a set oftemplate behaviors, or may be explicitly programmed, through theinterface provided by configurator 141 and director 121. For example, inan occupancy response behavior, parameters could govern the length oftime required without an indication of occupancy after which anilluminator 111 would conclude that there are no humans present.Similarly, parameters could govern the amount and/or type of signalrequired from motion detection sensor 461 used for occupancy detectionthat should considered as a positive indication of occupancy.

In addition, director 121, voice command, or other means may be used torequest adjustment of the behavior parameters. For example a human couldrequest explicitly that the timeout period and/or detection thresholdsbe increased/decreased without explicitly specifying actual parametervalues. Also, the system can learn from human responses to adjust thedetection parameters, for example increasing the timeout if it detectsan immediate and/or particularly vigorous human response upon decreasingthe illumination. Such autonomous adjustment behaviors can in turn beselected from a set of behavior templates and specified for systemelements without explicitly specifying parameter values.

3.15 Alarm and Security Functions

Sensors in illuminator 111 can act as part of an alarm or buildingmanagement system. When an illuminator recognizes an unusual conditionsuch as detected motion during times when the space is expected to beunoccupied, or high or low temperatures possibly indicating an HVACfailure or fire, or power failure conditions, information about thatcondition can be delivered to an alarm or building management system, aswell as triggering behaviors for that or other illuminators 111.

For example, detection of motion at inappropriate times could cause allilluminators 111 in an area to illuminate, as well as triggering analarm for the building management system. Similarly, an out-of-rangetemperature could cause illuminators to blink in order to attract humanattention.

Another security-related function is the ability to identify and locatewhere people are present in a building through use of the same sensorsused or occupancy detection. In an emergency situation, this informationcould be used to assist emergency response personnel in locatingpersons.

Another security-related function is the ability to monitor the ambientsound or video environment using sound or image sensors and transmitsound or images back to a monitoring system in the event that apotential intrusion is detected.

Alarm and security indications based on such sensors would typicallyemploy different thresholds and parameters for detecting intrusions(i.e., occupancy when none is expected) than when detecting occupancyprimarily for control of illumination.

Another example of integration with security functions would be to usethe occupancy-detection information obtained from the ICN system totrigger changes in the security state for a building. For example, thedoors into an area could be automatically locked when there are nooccupants, but kept unlocked whenever people are present. Such behaviorcould be occur, for example, only during specifically configured timeperiods.

3.16 Battery Management

In some applications (e.g., solar-powered illuminators, emergencylighting), illuminator 111 may incorporate a battery power supply.

In an emergency lighting application, illuminators 111 used for generalapplication can also be used to provide emergency lighting under batterypower. In such applications, only a subset of illuminator 111 may beconnected to batteries, and the light that they provide when line poweris unavailable may be optimized for power efficiency rather thanbrightness, color balance, or other characteristics.

The battery management behavior can make adjustments to use thebattery's available lifetime most efficiently, for example by reducingbrightness (and thus power consumption) as available battery powerdecreases. This changes can be time-driven (and associated with thesolar illumination cycle anticipated for the time of year), so that, forexample, battery power is consumed at a rate that ensures some light isavailable for the entire period when the sun is not present, even if(for example) the previous day's inclement weather only allowed apartial battery charge.

Illuminator 111 can provide status information about the current stateof the battery and its charge (for instance, by reporting voltage and/orcurrent flow into the battery). It can also conduct controlled-dischargetests to measure the current quality of the battery, in order to predictwhen a battery is reaching the end of its lifetime and will needreplacement.

Battery status can be reported as part of status reporting; it can alsobe indicated directly by the illuminator. For example, in an emergencylighting application, an illuminator can introduce a small periodicmodulation of light intensity that is clearly visible to a person butthat does not significantly interfere with providing light.Alternatively, light intensity can be decreased as battery capacitynears exhaustion, to maximize availability of light.

It will be evident that not all illuminator 111 in an installation wouldnecessarily require battery backup, as satisfactory emergency lightingmay only require that a limited subset of illuminators be involved.Additionally, it will also be evident that multiple illuminators canshare a single battery, with the individual controllers determiningautonomously which one(s) is/are responsible for managing the chargingof the battery.

3.17 Leasing Control

It is possible to utilize the software-based controls executed incontrol microprocessor 401 to allow some parties to control or limit theusage of functions of illuminator 111 by other parties.

For example, in a building containing a lighting system controlled by anICN system, the building's owner(s) and/or tenant(s) may lease thelighting system from another party, the lighting system lessor. Thelessor can maintain logical possession of the lighting system byexercising control over the software that runs in illuminators 111components so that some or all illuminator functions become inoperableor limited if some such software or control parameter data is notupdated on a regular basis by the lessor. Removing or limitingavailability of control functions would allow the lessor to virtuallyrepossess the leased lighting system in the event of lease non-payment.Similarly, such leasing controls could be applied by a building owner tomultiple individual tenants within the building.

As another example, because the capital cost of some advanced lightingtechnologies (e.g., LEDs) is relatively high compared to the costincumbent technologies (e.g., fluorescent lamps), the ability to leaselighting equipment can provide a valuable economic benefit to thelessee. The ability for the lessor to retain effective control of theequipment through the software control mechanisms described hereinallows the lessor to engage in such transactions with an acceptably lowlevel of risk. In such a case, the lessee can substitute an operatingcost for a higher initial cost, and the lessor can finance the equipmentattractively because the risk of loss is countered by the controlmechanisms.

As another example, the owner or supplier of ICN-based systems couldselectively supply control behaviors to customers on an individuallypurchased (or otherwise controlled) basis. This capability would enablea variety of business models beyond simple purchase; for example, asupplier could allow a building operator to have a six-month trial ofsome function (such as occupancy-sensing behavior) such that theoperator could then decide (e.g., based on the cost savings experienced)whether or not to purchase that capability on a permanent basis.

As another example, the mechanism of controls and reporting describedhere could be used to report energy consumption and to calculate energysavings, enabling multiple parties to share benefit from the reductionin actual energy costs. Because it can be collected and reportedsecurely, that data could, for example, be used as a basis for rebatesfrom an energy supplier.

As another example, the approach of allowing an external party to adjustcontrol network behavior can be applied to allow an energy supplier(e.g., public utility) to send remand-side load management requests tothe network, requesting that the energy consumption of some or all thecontrolled devices be reduced or eliminated. A utility, for example,could request that lighting levels be reduced by 25% (which for LEDlighting with current control would typically result in a greater than25% energy savings) during some period of time, and provide apreferential rate for power during that time period.

It will be evident that although the ICN architecture provides apreferred embodiment of the concepts described herein, the enforcementof business rules such as property leases can be implemented in manyother types of control system.

The duration of a lease could be expressed in terms of, for example,calendar time, operating hours, and/or energy consumption. For example,a lessor might specify that lease payments are due on a monthly basis,or for every 1000 kilowatt-hours consumed by the entire lighting system,or for every 1000 operating hours accumulated for each fixture. Usingthe ICN capability for grouping and/or location identification, leaseduration could be specified in terms of rooms, floors, areas, and/orother groupings.

The lease could be implemented by running a lease control behaviormodule 801 in controllers 301 that would measure the elapsed time,operating hours, energy consumption, and/or other lease controlparameter. When the lease parameters were reached or exceeded, the leasecontrol module could respond by disabling the controlled device entirelyor by selectively limiting the control behaviors that it can exhibit.

As long as the lessee is in good standing, the lessor would supply, on aperiodic basis, new lease control behavior modules 801 and/or leaseparameter data for such modules, so that no functional limitations wouldbe experienced.

In addition, a lease control module could implement multiple limits, sothat different limitations apply depending on how far the leaseparameters had been exceeded. For example, a lease could specify thatcontrolled lighting would operate at only 50% brightness in the firstmonth that the lease parameters are not met, and reduce further to 25%in the second month, and to flicker or blink annoyingly after the thirdsuch month. Alternatively, desirable behaviors could be disabled whenthe lease terms are not met, such as disabling occupancy sensing andleaving lights on at all times—thus increasing the lessee's energycosts.

Sub-leasing and delegated control can be implemented in such aframework. A building owner and/or property manager could specifydifferent terms for different groups of controllers 301, allowing leaseterms for individual tenants in a building to be specified and enforcedindependently. Multiple levels of lease terms could apply concurrently;for example, the system supplier might have a set of terms that apply toan entire building, in the case that the property manager is the actuallessee for the system, and the property manager could in turn sub-leaseuse of the ICN system to individual tenants.

In a delegated situation (e.g., a building owner that sub-leases theICN-controlled functions to multiple tenants), a lessee's minimum usagerights could be guaranteed by the lighting system supplier. A tenantcould use configurator 141 or director 121 to obtain accurateinformation about the limits applied by each level of lessor.

Lease behavior modules and/or parameters can be delivered over theInternet or other networks, either on a demand (“pull”) or delivery(“push”) basis. Delivery can be made through a gateway 161 component,configurator 141 and/or director 121 components, or any appropriatecombination. Delivery can be periodic and automatic, ensuring, forexample, that a lessee in good standing does not experience unwarrantedservice interruptions. In the event that some failure or unexpectedcircumstance makes a delivery mechanism inoperable, the ICN software(e.g., in controllers, directors, and/or configurators) can give thesystem user an indication that the expected delivery has not occurredand may result in a service interruption if the fault is not remedied.

4 Communication

Every controlled appliance 101 (e.g., illuminator 111, controlled powersource 102; that is, any element that incorporates controller 301), aswell as every director 121, gateway 161, and combinedconfigurator/director 151 incorporates at least one communicationinterface 501. Typically, communication interface 501 is bi-directionaland can both send and receive messages (not necessarily simultaneously);however, in some cases (e.g., fixed function director 122), only aone-way interface is required.

Controllers 301 and directors 121 communicate with each other to receiveand acknowledge requests, to deliver reports, and to forward requeststhroughout a constellation of controlled appliances 101. Controllers 301communicate with each other to forward and deliver messages of all typesand to ensure, through use of acknowledgments, that messages aredelivered to all controllers that are intended to receive them.

Communication can be viewed as three logical layers: the physical layerused to transmit bits from one component to another; the network layerused to manage communication among the components; and the applicationlayer, used to coordinate the activities of multiple components.

The physical layer is implemented in part by communication interface501, which is a hardware component that sends and receives data.Software running in control microprocessor 401 may implement part of thephysical communication layer as well, performing modulation anddemodulation to transform between raw electromagnetic signals used bycommunication interface 501 and digital data comprising messages. Commonphysical communication techniques are infrared and ultrasound, althoughradio, hardwired, power line modulation, and/or other techniques canalso be used if appropriate.

The network layer provides for transport of data between senders andrecipients, and also may provide either a direct or emulated multicastcapability. In the ICN architecture, the data transfers are almostalways short, so communication can be optimized for such traffic.

The application layer manages message exchanges between software modules801 running in different controllers 301, enabling them to coordinatetheir activities and providing a reliable transmission service to storeand forward messages.

Gateway 161 elements can be used to integrate the ICN communicationmechanisms with other networks, allowing information (such as requestsand reports) to be delivered over the Internet and/or private networks.Conventional network security mechanisms (e.g., authentication,encryption, firewalls) can be used to protect an ICN network fromunauthorized use or access. An ICN network can also be used as transportfor information from other networks, e.g., by mechanisms such as IPtunneling. Integration with the Internet and private IP networks allowsICN elements to be controlled and interrogated from arbitrary locations,facilitating remote control and building management.

4.1 Physical Layer

A variety of physical layer communication mechanisms may be used bycontroller 301. In some cases, it is advantageous to combine multiplecommunication interfaces 501 in a single controller 301.

Infrared has the advantage of being effective in approximately the sameregion that the light itself is present, giving it the intuitiveproperty (for illuminator-type devices) that if two illuminators providesome illumination to the same area, they are also able to communicate.Another desirable characteristic of infrared (and one it shares withultrasound) is directionality: it is easy to point a narrow-beaminfrared director at a specific illuminator to deliver a request.Infrared is more than fast enough for ICN: it can easily run at 1megabit/second.

Ultrasound has somewhat different propagation characteristics thaninfrared, although typically not enough to matter, and in some cases(e.g., through doorways and archways) may be desirably better. It hasthe advantage that it can easily be used for distance measurement andtherefore location determination among a group of illuminators or otherdevices. Ultrasound is not particularly fast: several kilobits/second isprobably a practical limit.

Radio is fast and can operate through building walls even at low power.This is not necessarily a desirable characteristic: in ICN applicationssuch as lighting control, as often it is desirable for requests to belimited to a single room or part of a room. The ZigBee standard isbecoming widely used for building controls, however, and integrationwith such systems is desirable. Such integration can be achieved throughgateway components, or through controllers equipped with radiointerfaces such as ZigBee in addition to other interfaces.

Power line modulation is an older, slower, and less reliable technology,and is typically one-way (for example, the X10 control interface).Supporting X10 appears straightforward as a software function, and couldbe useful in some environments, but it is not suitable as thegeneral-purpose interface required by the ICN architecture. The newerInsteon powerline modulation interface is also feasible to implement.

Light output modulation is a possible interface. It has the advantage(over infrared) that its reach is completely evident and intuitivelyunderstandable. However, in the ICN application its use may bechallenging if pulse-width modulation? brightness control is also used,as that will introduce considerable noise and a challenging modulationproblem for physical communication layers relying on carrier sensemultiple access (CSMA).

Wired control mechanisms, such as the DMX, DALI, and/or Echelonprotocols, can also be used to deliver requests to controllers, but theyare not suitable as the general-purpose ICN communication mechanism.

Additionally, voice response may be implemented as a softwareapplication in a controller. It could be used for delivering requests,which could typically be acknowledged by a quick blink or simply by therequested action having taken place.

4.2 Network Layer

The ICN network layer is typically a low-latency mesh network. Such anetwork can be adapted from widely-available technologies, such as theIEEE 802.11 infrared network standard and the ZigBee mesh networkingarchitecture.

In some applications, it is desirable for the network layer to allowlow-latency interactions between directors and controllers, so thathuman operators do not perceive any delays. For this reason, it may beadvantageous to remove or limit some of the mechanisms defined fornetworking standards to optimize performance in the ICN system, whereshort messages are the norm and latency, not throughput, is often theprimary consideration.

Several basic principles drive the design of the network layer:

-   -   Every controller is treated as a node in a distributed mesh        network    -   Messages may be addressed to a specific node or to a logical        group of nodes    -   Messages are forwarded to by nodes to other nodes in a group    -   Every message is acknowledged, and retransmitted if not.    -   The network is optimized for rapid delivery of messages to such        logical groups    -   The network is optimized for delivery of relatively small,        fixed-size messages; larger messages are constructed at the        application layer.        4.3 Application Layer

A function of the application layer is to ensure reliable messagedelivery from an originating sender to one or more recipients and/orgroups of recipients. Because not all system components may beoperational (for example, some devices may not have power when themessage is sent) when a message is entered into the system, othercomponents would typically be able to store messages and queue them forlater delivery.

A protocol such as the XNS Clearinghouse Protocol can be used toaccomplish such delivery, particularly adapted for the network and groupcharacteristics of the ICN system.

In large ICN systems, it is typically necessary for some components toact as gateways, using alternative communication interfaces to delivermessages over long distances or through barriers (such as walls) wherethe normal interface (e.g., infrared) cannot be used. Thestore-and-forward processing can take advantage of these gateways toensure reliable delivery throughout the system.

5 Controller Software

Software running in control microprocessor 401 is responsible forimplementing all the control, communication, monitoring, and behaviorfunctions performed by controller 301. Because cost is typically animportant consideration for the implementation technology of controller301, the software is typically optimized to minimize resourcerequirements and runtime cost.

Activities typically occur within control microprocessor 401 on pluraldistinct timescales. In the example embodiment of illuminator 111, thosetimescales include high-rate, medium-rate, and low-rate activities.

Mid-rate activities are timer-driven and typically occur at 480times/second (that is, within a “housekeeping interval” of just over 2ms.). They activities include management of the high-resolution softwareclock, adjusting power control parameters, scheduling high-rateactivities, and monitoring sensor inputs. The 480 per second rate ischosen to be easily synchronized with the AC power line and to be abovethe typical minimum threshold for LED pulse-width modulation timing toeliminate thermal stress from cycling LED power.

High-rate activities are both event-driven and timer-driven, and canoccur at rates up to 25,000 times/second. High-rate activities includeLED power control setting, IR transmitter bit generation, and IRreceiver bit recognition. High-rate activities are very precisely timedwithin the housekeeping interval, using a high-resolution hardware timerrunning at the processor's clock frequency.

Low-rate activities occur at much lower time scales than thehousekeeping interval: typically seconds or minutes. These includevarious types of status monitoring and communication.

In the example embodiment of illuminator 111, control microprocessor 401in controlled 301 would typically run control software 402 consisting ofthe following elements, as shown in FIG. 8:

Operating system supervisor 811

Housekeeping interrupt handler 821

Power control interrupt handler 822

Communication receive interrupt handler 823

Communication transmit interrupt handler 824

Communication message layer 831

Communication network layer 832

Module manager 841

Security library 842

Plural behavior modules 801

Plural external parameter blocks 802

Plural internal data blocks 803

Additional software components may be present in control software 402,depending on the specific functions to be performed by controller 301.As one example, additional hardware functional units or sensors may havespecific interrupt handler components. As another example, atest/debug/configuration component may be present. As a third example,other communication interfaces 451 might require additionalcommunication interrupt handlers 823 and 824 and/or communicationcomponents. Such components may be part of the basic control software401 or may be dynamically installed and/or removed as behavior modules801.

5.1 Summary of Control Software Components

Operating system supervisor 811 is a tiny real-time operating systemkernel that supplies services for task dispatching, inter-taskcommunication, and memory management.

Housekeeping interrupt handler 821 is a timer-driven interrupt-handlingmodule that performs the mid-rate housekeeping tasks. It keeps track ofreal time and ensures that high-rate and low-rate activities arescheduled appropriately.

Power control interrupt handler 822 is a timer-driven high-rateinterrupt handler that controls MOSFET switches 711 to controlillumination of LEDs 701. It may implement a pulse-width modulation(PWM) or other modulation scheme to adjust brightness and color. Tominimize interrupt cost, power control interrupt handler is driven bydata in LED control table 2101.

Communication receive interrupt handler 823 processes interrupts fromcommunication interface 751, which typically indicate receipt of one ormore bits of a network message, and which are deposited into a messageinput buffer, but may also be noise that can be recognized and rejectedby communication receive interrupt handler 823. Communication receiveinterrupt handler 823 is typically invoked only in response to externalevents and is not timer-driven.

Communication transmit interrupt handler 824 is a timer-driven modulethat controls the output (transmit) aspect of communication interface751. It is driven by data read from outgoing message 2301.

Communication message layer 831 is responsible for formatting andaddressing network messages, managing input and output buffers. It setsup the parameters and buffers that drive communication interrupthandlers 823 and 824, and performs other typical tasks associated withthe Open Systems Interconnection (OSI) layered network model.

Communication network layer 832 is responsible for managing applicationcommunication in the overall network of controllers 301, ensuring thatmessages are delivered to required recipients, processingacknowledgments, and performing other typical communication tasksassociated with the Network and Session layers of the OSI network model,managing input and output buffers. It sets up the parameters and buffersthat drive communication interrupt handlers 823 and 824.

Module manager 841 loads and unloads behavior modules 801 and associateddata blocks 802 and 803. It is responsible for validating modules,managing memory, maintaining associations between modules and datablocks, associating modules with network message types delivered bynetwork layer 832, managing dependencies among modules, assemblingmodules from fragments during module download and delivery, and othertasks associated with behavior modules 801. Module manager 841 is alsoresponsible for managing dynamic updates to other software components ofcontrol software 402, and for updating and accessing external parameterdata blocks 802 and internal data blocks 803.

Security library 842 provides cryptographic functions forauthentication, encryption, decryption, key management, and otherpurposes. Cryptographic functions can used by module manager 841 tovalidate modules, by communication message layer 831 or network layer832 to protect network messages, and/or for any purpose required in somebehavior module(s) 801.

Behavior module(s) 801 are executable modules that can be loaded inarbitrary combinations into control microprocessor 402. They canimplement above-described behaviors and/or arbitrary other functions. Abehavior module 801 typically has an associated external parameter datablock 802 that specifies parameters to control the behavior, and mayalso have an associated internal data block 803 that maintains,internally to control microprocessor 401, non-volatile storage forinformation relevant to that behavior module 801. Behavior modules 801can have metadata that identifies dependencies and allows for versionmanagement.

Some components of control software 402 and of typical behavior modules801 are described further below as examples of how implementationrequirements may be satisfied. It will be evident to one skilled in theart that these are only examples, and that the functions described inthis section and in section 3, Illuminator Behaviors, can be implementedin a variety of ways using different approaches, using well-knownalgorithms for distributed computing.

For example, to implement any particular distributed behavior, theilluminators can agree on (“elect”) a single master illuminator, whichthen becomes responsible for polling and/or receiving announcements ofrequests and state changes. The master illuminator in such an embodimentmaintains state associated with all the illuminators involved in thedistributed behavior, and issues appropriate requests to relevantilluminators to achieve the intended results. Such a single-masterapproach is often simpler to implement than a true distributedalgorithm, but requires successful execution of an election algorithm,and also requires a technique for recovering if the master illuminatorbecomes inoperable.

As another example, illuminators can use broadcast messaging to keepeach other informed about state changes, such that all illuminators in agroup can maintain accurate, or nearly-accurate, representations ofglobal state, and adjust their own state accordingly. Such an approachis most appropriate for behaviors involving stimuli that may be detectedby an arbitrary single illuminator (e.g., voice recognition, occupancyresponse, alarm response), yet must be acted upon by many illuminators.

It will be evident that components of control software 402, inparticular behavior modules 801, can be implemented as code that isdirectly by control microprocessor 401 and/or, optionally, asinterpreted code that is interpreted by a virtual machine or interpretersuch as Java, Forth, or other interpreted or threaded executiontechnique. Such alternative execution techniques have the potential toreduce code size, minimize risk of code implementation errors, and/orsimplify the code development process. Such alternative executiontechniques may require additional software components in controlmicroprocessor 401 to implement the interpreter and/or virtual machine.

5.2 Control Microprocessor Functions

For purposes of this example embodiment, control microprocessor 401 isassumed to include the following hardware functional units, shown inFIG. 9:

Central processor 901

Random access memory (RAM) 902

Non-volatile memory (NVRAM) 903

Priority interrupt dispatcher 910

High-resolution 16-bit hardware timer A 911

High-resolution 16-bit hardware timer B 912

16-bit clock comparator register A 921

16-bit clock comparator register B 922

LED control signal output port 931

Communication input/output port 932

It will be evident to one skilled in the art that different hardwareconfigurations for control microprocessor 401 can be equally effectivethrough straightforward changes in software implementation.

5.3 Power Control Interrupt Handler

Power control interrupt handler 822 is the interrupt-handling modulethat adjusts LED control MOSFET switches 711. During each housekeepinginterval, each of LEDs 701 may be on for some part of the interval andoff for the remainder (in the limiting cases, LED 701 may be on or offfor the entire interval). Controlling the LEDs to achieve this resultmeans that each MOSFET switch 711 must change state twice during theinterval (except in the limiting cases, which can be disregarded): oncein the middle of the interval, and again at the end. At the beginning ofeach housekeeping interval, deadlines—typically as many as there areLEDs, or more to implement randomized pulse-width modulation—aredetermined relative to the start of the interval, and thehigh-resolution timer is set up to invoke power control interrupthandler 822 at those deadlines. Each time that power control interrupthandler 822 is invoked, it updates the state of control signals 341 toreflect the required state of LEDs at the current deadline. Powercontrol interrupt handler 822 is a very simple piece of code: it simplytransfers state from an entry in a table to the appropriate controlsignals 341, then updates the pointer designating the current tableentry.

As shown in FIG. 10, power control interrupt handler 832 is invoked byreceipt of a timer interrupt (2151) from high-resolution timer A 911, Itreads the high-resolution timer (2152), then obtains the value ofdeadline 2104 specified by the current control table entry 2103 (thatis, the one designated by control table index 2111) in the current LEDcontrol table 2101, which is designated by control table pointer 2112.The deadline value is compared (2153) to the timer value. If thedeadline has not passed (2154), processing is assumed to be complete.The clock comparator (which will trigger the next interrupt) is set tothe deadline (2161) and the interrupt handler exits (2162). If thedeadline has passed, control data 2106 is obtained from the currentcontrol table entry and transferred (2155) to LED control register port931. Control table index 2111 is updated (2156) to designate the nextcontrol table entry. If the table has not yet been exhausted (2157),control transfers back to the initial test (2152). Otherwise, controltable index 2111 is set (2157) to designate initial control table entry2103 in control table 2101 and the interrupt handler returns (2158).

5.4 Communication Transmit Interrupt Handler

Communication transmit interrupt handler 824 operates similarly to powercontrol interrupt handler 822, except that it uses secondhigh-resolution hardware timer B 912 to schedule its interrupt, and itcalculates timing for its interrupts directly from the data in outgoingmessage 2301, rather than having a distinct data structure describingdeadlines such as LED control table 2101.

Communication transmit interrupt handler 824 is active only when thereare outgoing messages not yet fully transmitted. At other times, secondhigh-resolution hardware timer B 912 is disabled.

FIG. 12 shows data structures associated with communication transmitinterrupt handler 824. Outgoing message table 2391 designates themessages 2301 waiting to be transmitted or acknowledged. Each message isdesignated (e.g., pointed to in memory) by slot pointer 2394; if amessage has been transmitted, message-sent flag 2392 is set; if amessage has been acknowledged, acknowledgment flag 2393 is set. For themessage currently being transmitted, located in message buffer 2397(which is simply another designation for the storage occupied by message2301), message pointer 2396 identifies (e.g. by pointer or index) thebyte in the message next to be transmitted. Message state 2395identifies what part of transmission is happening: start-of-messagepattern, end-of-message pattern, bit position within current byte (forexample, in the preferred embodiment of 4-bit pulse interval modulation,bit position would indicate either the high-order or low-order fourbits).

5.5 Communication Network Layer

Communication network layer 832 is responsible for reliably deliveringmessages, potentially to a group (multicast) address.

FIG. 13 shows the principal data structures used by communicationnetwork communication layer 832: message 2301, neighbor table 2381,outgoing message table 2391.

Message 2301 consists of sender address 2311, physical receiveraddress(es) 2312, logical receiver address 2313, message ID 2314,message type 2315, message priority 2316, and message data 2317.

Neighbor table 2381 has one entry for each neighboring controller 301known to be reachable through communication interface 451. The tableentries contain physical address 2382 for the neighboring controller,group list 2383 that identifies the logical groups that the neighborbelongs to, and status 2384 that records the current reachability statusof the neighbor. Neighbor table 2381 is created when controller 301joins the network, and is updated as other controllers join or leave thenetwork and communication reachability changes, and as group membershipchanges.

Outgoing message table 2391 is a queue (ordered by message priority 2316in each message 2301) of slots pointing to messages 2301 that arewaiting to be delivered by communication message layer 831 using theservices of communication transmit interrupt handler 824.

FIG. 14 shows a simple example of message delivery and forwarding to agroup of controllers. This function is a core function for networkcommunication layer 832, since it underlies all the distributedprocessing behaviors described above.

Message 2361A (sent by director 2342) is received by first illuminator2341A. Message 2361A has a physical receiver address 2312 of “any”, anda logical receiver address of “Group-7”.

Illuminator 2341A consults outgoing message table 2391 to see if message2361A has been processed already (i.e., if its message ID 2314 ispresent in table 2391). If so, it ignores message 2361A. This situationcan occur, for example, if message 2361A has been forwarded throughseveral other illuminators before finally returning to illuminator2341A.

Since message 2361A has a non-null sender address 2311, illuminator2341A sends acknowledgment 2371A to director 2342.

Illuminator 2341A consults neighbor table 2381 to determine whether anyof its neighboring illuminators belong to the addressed group(“Group-7”). For each neighbor belonging to the group, illuminator 2341Acreates a copy of message 2361A, identical to the one it received exceptfor sender address 2311 (which is set to “Illuminator A”) and physicalreceiver address 2312 (which is set to the address of the identifiedilluminator) and records it in outgoing message table 2391. In thisexample, illuminators 2341B and 2341C are the two that belong to“Group-7” and will be addressed by messages 2361B and 2361C.

Communication message layer 831 in illuminator 2341A processes thequeued messages 2361B and 2361C and sends them.

Also, if illuminator 2341A belongs to “Group-7”, communication networklayer 832 routes message 2361A to appropriate behavior modules 801 forprocessing.

In this example, illuminator 2341B receives message 2361B. It recognizesit as being addressed to it and processes the message in the same manneras illuminator 2341A. Because the message came from illuminator 2341A,illuminator 2341B does not send a copy back, but it does send a copy2362C to illuminator 2341C, and a acknowledgment 2372A back toilluminator 2341A

In this example, illuminator 2341C does not successfully receive eithermessage 2361C or message 2362C (perhaps because they were transmittedsimultaneously, causing a collision that damages both messages). Bothilluminator 2341A and illuminator 2341B are waiting for acknowledgmentmessages; when those acknowledgments do not arrive, each waits apseudo-random length of time (to avoid collisions) and sends retrymessages 2363C and 2364C.

Illuminator 2341C successfully receives message 2363C, processes it asdescribed above, and sends acknowledgment 2373C back to illuminator2341A.

Illuminator 2341C also successfully receives message 2364C, butrecognizes it as a duplicate because message ID 2314 has already beenrecorded in its outgoing message table 2381. Illuminator 2341C alsosends acknowledgment 2374C back to illuminator 2341B, preventingredundant message traffic.

5.6 Distributed Occupancy Sensing

Controller 301 can run an instance of behavior module 801 implementingdistributed occupancy sensing as described above in section 3.6,Occupancy Response.

Sensors used for occupancy detection typically are inherently noisy;that is, they may generate electrical signals even when no actualoccupancy event has taken place. The software implementing occupancyresponse can employ signal processing algorithms to eliminate theeffects of such noise and calculate an average value of occupancyindication that can be compared against thresholds to trigger behavior.Thresholds can be pre-determined, adjusted explicitly by a system user,and/or adjusted automatically in response to detected behavior.

FIG. 16 illustrates how a single illuminator could implement occupancyresponse behavior; FIG. 15 shows the data elements used by the processshown in FIG. 16. Current thresholds 2401 consists of current lowthreshold 2402 and current high threshold 2403, and is a dynamic datastructure that governs the behavior of the illuminator 111 while it isoperating. Dark thresholds 2411 consists of static default values thatare transferred into current thresholds 2401 when illuminator 111 entersan active unlit condition (e.g., when occupancy sensing determines thatthere are no occupants). Similarly, light thresholds 2421 consists ofstatic default values that are transferred into current thresholds 2401when illuminator 111 enters an active lit condition (e.g., whenoccupancy sensing determine that occupants are present, or whenexplicitly commanded to be on). Decaying average 2431 represents theaverage output level from an occupancy sensor over a recent timeinterval. Occupancy timeout timer 2441 consists of timer value 2443,timer limit 2444, and timer enabled flag 2441. When the timer isenabled, its value is incremented at every sampling interval. Typically,light thresholds 2421, dark thresholds 2411, and default timeout limit2445 would be contained in external parameter block 802 associated withbehavior module 801 implementing the occupancy detection behavior. Eachthreshold has two values, between which no state changes. Two valuesprovide a degree of hysteresis in operation; they could be combined to asingle threshold.

As shown in FIG. 16, occupancy response algorithms implemented bybehavior module 801 would typically run a loop. Each iteration beginswith a timer interrupt (2500) that typically is generated byhousekeeping interrupt handler 821. The software obtains the currentvalue of the occupancy sensor (2501) and combines it with decayingaverage value 2431 to obtain a new value for the average (2502).

If occupancy timer enabled flag 2442 is set (2503), occupancy timervalue 2443 is increased by one (2511).

Decaying average value 2431 is compared with current low threshold 2402(2504); if decaying average value 2431 is lower than the threshold,occupancy timeout timer 2441 is cleared and started (2521) by settingoccupancy timer value 2443 to zero and setting occupancy timer enabledflag 2442.

Decaying average value 2431 is compared with current high threshold 2403(2505); if decaying average value 2431 is higher than the threshold,occupancy timeout timer 2441 is stopped (2531) by clearing occupancytimer enabled flag 2442. If illuminator 111 is currently off (2532), itis turned on (2533). Current thresholds 2401 are set to the values oflight thresholds 2421 (2534).

If occupancy timer value 2443 exceeds occupancy timer limit 2444 (2506),illuminator 111 is turned off (2541), current thresholds 2401 are set tothe values of dark thresholds 2411 (2542), and occupancy timer 2441 isdisabled (2543).

Once the processing loop is completed, the software waits for anothertimer interrupt (2507).

The occupancy response for a single illuminator shown in FIG. 16 can actas a basis for distributed occupancy sensing. For example, whenever step2533 are executed, to turn the light on, first illuminator 111 canbroadcast that decision to second illuminators 111, by sending amessage, instructing them to take the same action, so that a singleilluminator detecting motion can cause an entire room to be illuminated,or to stay illuminated.

As another example, rather than executing step 2541 immediately to turnoff a light, first illuminator 111 can broadcast a message indicatingthat it intends to turn off the light, and remember the fact that thelight is ready to turned off without actually turning off the light. Ifany other illuminator has not yet reached the same state (i.e., is stillilluminated and is waiting for its own occupancy timer 2441 to expire),it responds with a message to first illuminator 111, to indicate thatits light should stay on. If first illuminator 111 receives no suchmessages within an appropriate interval, it turns off its light andbroadcasts a message to other illuminators directing them to turn off aswell.

If illuminator 111 turns off the light (step 2541) and then promptlydetects occupancy (step 2505), this situation indicates that the roomwas occupied, that the occupants reacted to the light being turned off,and therefore that current threshold values 2401 were insufficientlysensitive. When illuminator 111 recognizes such a situation, thresholdvalues can be adjusted to make the situation less likely to occur in thefuture.

Current threshold values 2401 and occupancy timeout limit 2444 can beadjusted in response to messages from other illuminators that indicatetheir history of occupancy sensor values.

Illuminator 111 can gradually adjust the brightness level up or down aspart of steps 2532 and 2541, rather than turning the light on and offsuddenly.

Illuminator 111 can blink the light or otherwise make a visible oraudible signal for occupants when a timeout is initially detected (2506)and allow the timer to run to another limit before turning off thelight. Such an indication can allow the occupant to respond while thelight is still illuminated, so that room illumination is not disrupted.

While this invention has been particularly shown and described withreferences to example embodiments thereof, it will be understood bythose skilled in the art that various changes in form and details may bemade therein without departing from the scope of the inventionencompassed by the appended claims.

What is claimed is:
 1. A lighting system comprising a plurality ofilluminators displaced relative to each other, each of pluralilluminators comprising: a light source; a sensor; a communicationsinterface communicating with other illuminators in a network; aprocessor responsive to the sensor, the processor controlling theilluminator; the processors of plural illuminators configured to makeillumination decisions through distributed processing across the networkbased on information exchange among the illuminators through thecommunication interfaces; and a plurality of radio-frequency gatewaysthat allow isolated portions of the system to communicate with eachother.
 2. The system of claim 1, wherein the gateways are integratedinto plural illuminators.
 3. A lighting system comprising a plurality ofilluminators displaced relative to each other, each of pluralilluminators comprising: a light source; a sensor; a communicationsinterface communicating with other illuminators in a network; and aprocessor responsive to the sensor, the processor controlling theilluminator; the processors of plural illuminators configured to makeillumination decisions through distributed processing across the networkbased on information exchange among the illuminators through thecommunication interfaces, wherein the processors forming the distributednetwork make lighting decisions according to a polling algorithm.
 4. Thesystem of claim 3, wherein the polling algorithm weights stimuli sensedacross the distributed network.
 5. A method for providing illuminationcomprising: at each of plural illuminators, emitting light from anilluminator, sensing stimuli with a sensor, and communicating with otherilluminators through a communications interface; processing responses tothe sensed stimuli across a distributed network of the pluralilluminators to make illumination decisions; and using radio-frequencygateways that allow isolated portions of the distributed network tocommunicate with each other.
 6. The method of claim 5, wherein thegateways are integrated into plural illuminators.
 7. A method forproviding illumination comprising: at each of plural illuminators,emitting light from an illuminator, sensing stimuli with a sensor, andcommunicating with other illuminators through a communicationsinterface; and processing responses to the sensed stimuli across adistributed network of the plural illuminators to make illuminationdecisions, wherein the processing across the distributed network makeslighting decisions according to a polling algorithm.
 8. The method ofclaim 7, wherein the polling algorithm weights the stimuli sensed acrossthe distributed network.
 9. A method for providing illuminationcomprising: at each of plural illuminators, emitting light from anilluminator, sensing stimuli with a sensor, and communicating with otherilluminators through a communications interface; and processingresponses to the sensed stimuli across a distributed network of theplural illuminators to make illumination decisions, wherein theprocessing comprises using a clock to control the timing of lightingdecisions across the network.
 10. A method for providing illuminationcomprising: at each of plural illuminators, emitting light from anilluminator, sensing stimuli with a sensor, and communicating with otherilluminators through a communications interface; and processingresponses to the sensed stimuli across a distributed network of theplural illuminators to make illumination decisions, wherein theprocessing comprises responding to instructions for reduced emission atan illuminator by controlling emissions by neighboring illuminators toproduce patterns of illumination.
 11. A method for providingillumination comprising: at each of plural illuminators, emitting lightfrom an illuminator, sensing stimuli with a sensor, and communicatingwith other illuminators through a communications interface; andprocessing responses to the sensed stimuli across a distributed networkof the plural illuminators to make illumination decisions, wherein theprocessing comprises learning reactions to stimuli according to atraining set.
 12. An illuminator that acts as a node in a distributedmesh network comprising: an LED light source; a wireless communicationinterface; and control circuitry associated with the wirelesscommunication interface and adapted to: receive a message addressed to alogical group of illuminators; determine if one or more neighboringilluminators belongs to the logical group of illuminators; forward themessage to each of the one or more neighboring illuminators belonging tothe logical group of illuminators; and control light emitted by the LEDlight source, wherein the illuminator is a mesh network node.
 13. Theilluminator of claim 12 wherein: the message includes a control request;and the control circuitry is further adapted to determine if theilluminator belongs to the logical group of illuminators, and if theilluminator does belong to the logical group of illuminators, controlthe light emitted by the LED light source based on the control requestsuch that all illuminators in the logical group of illuminators respondto the control request as an associated group.
 14. The illuminator ofclaim 12 wherein the control circuitry is further adapted to send acontrol request via the wireless communication interface to at least oneof the one or more neighboring illuminators.
 15. The illuminator ofclaim 12 wherein the control circuitry is further adapted to: receive afirst control request via the wireless communication interface from afirst one of the one or more neighboring illuminators and control thelight emitted by the LED light source based on the first controlrequest; and generate and send a second control request via the wirelesscommunication interface to the first one of the one or more neighboringilluminators.
 16. An illuminator comprising: an LED light source havingat least one LED; a wireless communication interface; processingcircuitry; and a memory coupled to the processing circuitry, the memorystoring instructions, which, when executed by the processing circuitrycause the illuminator to: assign a new identifier to the illuminatorbased on interaction with one or more other illuminators via thewireless communication interface such that the illuminator and the oneor more other illuminators are each assigned different identifiersautomatically without manual intervention; and control light emitted bythe LED light source.
 17. The illuminator of claim 16 wherein the memorystores further instructions, which, when executed by the processingcircuitry cause the illuminator to provide the new identifier to adirector via the wireless communication interface.
 18. The illuminatorof claim 16 wherein the memory stores further instructions, which, whenexecuted by the processing circuitry cause the illuminator to update thenew identifier.
 19. The illuminator of claim 16 wherein the memorystores further instructions, which, when executed by the processingcircuitry cause the illuminator to automatically initiate interactionwith the one or more other illuminators via the wireless communicationinterface to assign the new identifier to the illuminator in response toinstallation of the illuminator.
 20. The illuminator of claim 16 whereinthe illuminator is a mesh network node in a lighting network and thememory stores further instructions, which, when executed by theprocessing circuitry cause the illuminator to receive a message from atleast one illuminator and send the message to at least one otherilluminator.
 21. The illuminator of claim 20 wherein the memory storesfurther instructions, which, when executed by the processing circuitrycause the illuminator to receive a control request via the wirelesscommunication interface from the at least one illuminator and controlthe light emitted by the LED light source based on the control request.22. The illuminator of claim 20 wherein the memory stores furtherinstructions, which, when executed by the processing circuitry cause theilluminator to send a control request via the wireless communicationinterface to the at least one illuminator.